Due to widespread availability of miniature processors and circuits for connecting to wireless networks, increasing numbers of devices are able to connect wirelessly with communication networks, such as the Internet. For example, electronic circuitry may be embedded in various types of devices (“things”), enabling communication with these devices over the Internet for any number of purposes, such as tracking, maintaining, updating and/or controlling the devices, or using the devices for remote sensing, monitoring, imaging, surveillance and/or data sharing, for example. The devices configured to communicate over the Internet may be referred to as Internet of Things (IoT) devices.
Typically, IoT devices are coin cell powered and very small in size. Accordingly, printed circuit boards (PCBs) that contain circuitry for establishing and maintaining wireless network connections and Internet communications (as well as for device control, in some instances) may be densely populated and have very complex layouts. Also, when the devices require manual assembly of radio frequency (RF) circuitry, power circuitry and the like, the difficulty of obtaining precise performance measurements and characteristics increases after final assembly. This is particularly problematic in that there is a relatively high chance of human error during the assembly process.
For manufacturing and quality assurance purposes, the PCBs include test points, as well as custom jigs, to create connections between the test points and external communication paths (e.g., HCl communication serial buses, and the like), in order to test various characteristics of the devices. The manufacturers also may need test mode firmware in the devices to accommodate the various tests. As these devices are typically inexpensive and quite small, they may or may not include sufficient memory (e.g., flash memory) to store both test mode and normal operational firmware. Therefore, during production, the manufacturers may need to perform extra steps in order to download test mode firmware for device testing purpose, and then download normal operational firmware for shipping the devices to end users. The extra steps require increased production time and complexity, resulting in increased expensive. Also, manufacturers may not have access to the test mode firmware, in which case they must contact the device (e.g., chip) manufacturer to support and/or provide the test mode firmware, which also can lead to increased production time and costs. These same issues are faced by end users that perform their own device testing.
Many IoT devices implement Bluetooth® low energy (BLE) wireless communication technology to enable connection to BLE wireless personal area networks (PANs) and ultimately to the Internet. A recent version of the BLE specification is BLE version 5.0, which provides for 40 physical channels in the 2.4 GHz ISM band, each separated by 2 MHz. BLE 5.0 defines two types of transmissions: advertising and data transmissions. Therefore, of the 40 channels, three are dedicated to advertising and 37 are dedicated to data. Also, many IoT devices implement ZigBee wireless communication technology to enable connection to ZigBee wireless PANs and ultimately to the Internet. A recent version of the ZigBee specification is ZigBee version 3.0, which provides for 16 physical channels from 2405 MHz to 2480 MHz, each separated by 5 MHz. ZigBee transmits and receives in a fixed channel(s), as opposed to channel hopping.
However, for device testing (e.g., in accordance with BLE and/or ZigBee specifications), only test mode non-signaling measurements are available. The non-signaling measurements require control by physical wire connection with the test system and the device operating in non-signaling mode. In the non-signaling mode, only modulated or continuous wave (CW) signals are generated. As mentioned above, the devices are typically very small, so they may not have space to populate the test points in the final PCB. Also, flashing of non-signaling firmware in the devices increases production time. Also, after performing tests using non-signaling (test mode) firmware, the manufacturer and/or end user needs to flash back the signaling (operational mode) firmware. The multiple flashings for non-signaling and signaling firmware increases production and testing time.
Accordingly, there is a need for a test system that is able to perform testing of a small device, such as an IoT device, without having to physically connect with the device circuitry (thereby avoiding the need to include test points on densely populated PCBs). The test system also needs to be flexible, since there are many different manufacturers and devices available, which are different in terms of functionality and behavior. So, there is a need for the test system to be able to resolve a diversity of issues without having to create customized firmware or settings for the different manufactures and/or the devices. There also is a need for a test system that is able to test devices that are running normal operational mode firmware, as opposed to test mode firmware.